\chapter{Conclusão}
\label{conclusao}

\section{Contribuições}
\label{contribuições}

Neste trabalho pudemos verificar que é possível a construção de uma ferramenta móvel de combate a fraudes em consursos públicos, utilizando-se impressões digitais eletrônicas, códigos de barras bidimensionais e técnicas de processamento de imagens, todos integrados num dispositivo computacional portátil, podendo ser utilizados durante a aplicação de provas de concurso.

Ficou também comprovado que a autenticação do candidato que passar no concurso pode ser feita por uma ferramenta que se utiliza das mesmas tecnologias, podendo garantir com alto grau de confiabilidade que o indivíduo que vai assumir a vaga é o mesmo indivíduo que foi avaliado no dia da realização da prova.

Por fim, podemos dizer então que esse trabalho alcançou seu objetivo principal, que era a construção de um protótipo funcional que comprovasse a viabilidade da solução proposta no trabalho anterior. O protótipo foi elaborado e os testes puderam ser realizados, nos permitindo a verificar que a solução realmente atende ao que se propunha, de forma eficiente e eficaz. 

No entanto, para que seja robusta e confiável o suficiente para ser considerada uma solução final, algumas atividades ainda precisam ser realizadas em eventuais trabalhos futuros. Essas atividades estão detalhadas na próxima seção. 

\section{Trabalhos futuros}
\label{trabalhosFuturos}

Existem muitas possibilidades de trabalhos futuros baseados neste projeto, como melhorias no processo, portá-lo para uma plataforma móvel, etc. As seções a seguir vão detalhar essas possibilidades.

\subsection{Mobilidade do módulo coletor}

Comprovada a eficácia da solução proposta, o próximo grande passo seria portar a implementação do módulo coletor para uma plataforma móvel. Isso possibilitaria o seu uso durante a aplicação de provas de concurso, onde seria complicada a utilização de um notebook. Uma boa possibilidade seria a plataforma Android, hoje largamente utilizada em \textit{smartphones} e \textit{tablets}. Sua principal vantagem seria o fato de ser implementada completamente em Java, assim como suas aplicações. Isso permitiria um grande aproveitamento do código já escrito para este protótipo. 

Outra vantagem da paltaforma seria a existência de câmeras digitais em todos os aparelhos, o que possibilitaria a captura de imagens do cartão resposta. Aplicações de manipulação do QRCode também já estão disponíveis para a plataforma, como por exemplo o Barcode Scanner, desenvolvido pelos mesmos criadores da API ZXing e que utiliza esta API para codificação e decodificação de símbolos QRCode. A figura \ref{figuraAndroidBarcodeScanner} mostra a aplicação Barcode Scanner lendo as informações do verso de um dos cartões resposta gerados por esse projeto.

\begin{figure}[h]
   \begin{center}
     \scalebox{0.5}{\includegraphics{imagens/android-qrcode.png}}
   \end{center}
   \caption{Aparelho celular com Android capturando um símbolo QRCode gerado por este projeto, com a aplicação Barcode Scanner.\label{figuraAndroidBarcodeScanner}}
\end{figure}

Quanto ao \textit{hardware}, processadores de mais de 1 Ghz já estão sendo embarcados nestes aparelhos, o que permitiria o uso de programas de processamento de imagens que requerem um poder de processamento razoável. A quantidade de memória \textit{RAM} disponível nestes aparelhos também seria suficiente para a execução de uma aplicação deste porte, variando de 128MB a 1GB.

Apesar dessas vantagens, algumas tarefas ainda precisariam ser realizadas para que o módulo coletor pudesse funcionar num dispositiivo Android: 

\begin{itemize}

\item \textbf{Leitura de digitais} - Este com certeza é o maior desafio para a construção de um módulo coletor realmente móvel. Conforme demonstrado no trabalho anterior, os aparelhos que possuem a função de leitura de impressões digitais são extremente caros e geralmente possuem muitas outras funções além das necessárias para este projeto, tornando-os inadequados. No entanto, começam a surgir alternativas para este problema, como por exemplo o leitor de digitais com comunicação via bluetooth fabricado pela Innovate Scan, chamado BlueFIN. Esse leitor é capaz de se conectar ao \textit{smartphones} Android e BlackBerry e fornecer leituras de impressões digitais.

\item \textbf{Substituição da API Griaule} - Este problema é decorrente do primeiro e se refere a API que cuida de todo o processamento das impressões digitais, a Griaule. Esta API pode funcionar em plataformas Windows e Linux, mas dificilmente poderia funcionar na plataforma Android. Sendo assim, toda a parte de interpretação da imagem da digital, geração do \textit{template}, \textit{enrolling} e \textit{matching} precisaria ser reimplementada usando outra API ou até mesmo sem uso de APIs de terceiros. 

\item \textbf{Transcrição do leitor do número de inscrição para Java} - Atualmente é utilizado por este protótipo o módulo de leitura do número de inscrição escrito em MATLAB, que foi elaborado pelo projeto anterior. Essa execução é feita através de uma API Java que na verdade chama o procedimento MATLAB, como descrito na seção \ref{melhoriaNumeroInscricao}. No entanto, essa execução do procedimento MATLAB requer a instalação de várias bibliotecas do MATLAB, o que seria impossível de fazer na plataforma Android. Dessa forma, a única solução possível é reescrever o procedimento MATLAB em Java. 

\item \textbf{Reformulação da Interface} - Devido as telas pequenas, toda a interface deste protótipo precisaria ser reformulada para a utilização em um \textit{smartphone}. Alguns desafios seriam encontrados nessa tarefa, como por exemplo exibir a imagem da câmera com tamanho suficiente para que o fiscal possa apontá-la corretamente para o cartão resposta, ao mesmo tempo sem deixar de exibir as outras informações relevantes para a operação.

\end{itemize}

\subsection{Melhorias no processo}

Algumas outras melhorias poderiam ser feitas, de forma a melhorar a solução proposta. Uma delas seria a possibilidade de escolha do dedo utilizado para extração da digital do candidato. Muitas pessoas possuem falhas na impressão digital em alguns dedos, sendo nestes casos a solução ideal a escolha de um outro dedo que não o indicador da mão direita para a coleta. Essa escolha está hoje fixa no sistema, o que pode diminuir a eficácia do sistema e causar problemas na hora da autenticação.

Outro ponto ainda em aberto é a questão da identificação dos indivíduos que não possuem impressão digital legível. Este é um caso bem raro, mas precisamos estar preparados para identificar todos os indivíduos. Nestes casos poderia ser realizada a captura da foto do indivíduo ao invés da impressão digital, sendo esta foto impressa na etiqueta ao invés do QRCode. Também podem ser utilizadas técnicas de reconhecimento facial, como sugerido no trabalho anterior.

No momento da identificação do número de inscrição também há um outro ponto a ser explorado: não há nenhum mecanismo de correção de erros. Este é um ponto bem crítico e de difícil solução, pois seria preciso mudar o gerador do número, visto que é inviável pedir para que o candidato forneça este tipo de informação. Atualmente é utilizado um método estatístico para tentar corrigir eventuais erros de leitura, conforme descrito na seção \ref{prototipoColetaNumero}. No entanto, este método não é confiável o suficiente para uma ferramenta que envolve questões de segurança, podendo levar a falhas graves de autenticação.

\subsection{Aspectos legais}

Um outro ponto ainda carente de pesquisas refere-se ao respaldo legal desta solução. Embora o método de comparação de impressões digitais eletrônicas seja altamente confiável, talvez possa ser contestado judicialmente. O método manual utilizado atualmente, que foi descrito na seção \ref{processo}, utiliza técnicas de papiloscopia há muito tempo legitimadas pelo Direito. Talvez uma espécie de homologação deste método de autenticação junto aos órgãos competentes seja necessária para sua validade judicial.


